A short history of ReScript (BuckleScript)

Hi there @bobzhang ! I have been following the Rescript/ReasonML discussion from a distance. I believe there is value to sticking with the OCaml ecosystem but also value in striking out in a new direction. There are benefits to both approaches – it only depends on how well they are executed.

Therefore, I respect the direction you outlined in your original post on this thread. You wanted to get rid of a lot of bloat. Getting rid of ReasonML means that you can have a performant front-end end without lots of legacy, also you can customize Rescript more to the needs of the Javascript ecosystem, have better error messages etc. All these reasons make sense to me.

So I’ll get to the point: Since Rescript decided to take a slightly separate direction, understandably the Rescript community lost out on a lot of OCaml ecosystem experts. I don’t know how high the likelihood would be to attract OCaml people to work on the aging 4.06 era Rescript backend. While there is a lot of work to be done in Rescript in the future, it feels that a lot of progress was made between 4.06 and 4.13 in OCaml (and more on the way). All that work seems to have been thrown away. If I understand correctly you’re still using the old 4.06 merlin backend in the Rescript LSP also. So while your frontend is sparkling and fresh your compiler backend is aging.

Some may argue that the current rescript OCaml 4.06 backend is “good enough” – it may be good enough for now but will it be good enough 5 years from now when the whole world would be on OCaml 5.x? Who knows what directions things will take with things like Webassembly etc on the horizon? Meanwhile Rescript would still be on the 4.06 island.

Suggestion
So may I suggest a slightly different approach. Please keep your backend upto date with OCaml! The melange project GitHub - melange-re/melange: A mixture of tooling combined to produce JavaScript from OCaml & Reason by @anmonteiro which is based on OCaml 4.12 shows you can keep your backend upto date with minimal effort.

I personally don’t care if rescript front end language kept diverging from the OCaml/ReasonML – as long as you are sticking to the OCaml backend then you will have people excited to work on the Rescript compiler. Right now, the prospect of working on a 4.06 era codebase may not be very exciting to a lot of people, I think.

I don’t know the compiler internals sufficiently to know if my suggestions make sense or not. The main point I’m indicating here is that you need some sort of a concrete link with the current OCaml ecosystem for people in that ecosystem to want to contribute to Rescript.

So the Rescript front-end language can continue to diverge but it needs to have some connection that is alive with OCaml. As an example, the mirage ecosystem does not have it own forked compiler – it pulls in the latest ocaml base compiler and works with it. Can’t the rescript compiler stay upto date with the OCaml backend automatically?

Once you have some link that is alive with (modern) OCaml you will find a lot people from the traditional OCaml ecosystem wanting to contribute.

7 Likes

Fable’s js code is pretty readable and the syntax is F#. The compile speed might not as fast, but does not matter that much. Few codebase as large as FB. Rescript might have some chance in the future, but I do not think it will achieve the popularity as TS. Personally, I give up Bucklescript after the rename to rescript. Tired of learning new syntax.

2 Likes

In my opinion, Rescript can succeed in the future if it only tries to re-combine its forces with the OCaml ecosystem again. Almost a year plus into the total separation, I can imagine the huge burden on the Rescript team – they need to do everything from soup to nuts (compiler, tooling, language…). It can be daunting and I’m sure they are up to the challenge but there is no reason why their journey has to be so lonely. In my reply above I’ve suggested how they can reestablish collaboration with the OCaml ecosystem.

The difference between TS and Rescript is that Rescript has fewer compromises. Though few code bases are very huge, instant transpilation really makes things easier during development. That is a big draw for Rescript and will continue to be.

ReasonML+Bucklescript was the pride and joy of the OCaml community. By doing a total separation (albeit for honest reasons) an unintended effect of that would be have been drying of the talent pipeline from OCaml (this is an educated guess, it could be the opposite – please correct me).

3 Likes

Could someone more familiar with the OCaml compiler internals, development process, and project governance, comment on the following:

  • Would it be possible to make ReScript a first-class citizen of the OCaml ecosystem, similar to ReasonML, by adopting and maintaining the changes to the intermediate language representation that enable such high quality JavaScript emission in the mainline OCaml compiler? The ReScript team can then focus on developing the ReScript language and the JavaScript emission backend module without having to constantly maintain and update a fork of the OCaml compiler.

  • If that were a goal we can agree is important to the OCaml community (and the fact that the v3 OCaml website is being built with ReScript is a proof that we don’t currently have a better alternative), what are the roadblocks? Technical issues? Manpower?

1 Like

It appears to me that the sudden separation effectively eliminated any excitement and momentum people had for ReasonML or Rescript. People who invested in this new thing and watched it grow suddenly saw that it was flimsy, capricious and unreliable, and that the ecosystem could be destroyed rather easily. I wouldn’t blame anyone who ran away from anything to do with those languages as a result.

11 Likes

ReScript wants to control their whole toolchain (who wouldn’t want to if they can make it happen?). That was the reason they branched out in the first place.

As this approach has brought them results so far, I don’t see them doing it any other way.

1 Like

Since most people don’t see the big picture, let me explain a bit about the current status and motivations.

  • Current status:

After we integrate the whole toolchain, the bug fix can be done very quickly. And changes to the type system is trivial and we managed to speed up the whole compiler by around 20%. This is non-trivial given that ReScript compiler/build is already the fastest on the market.

The ReScript compiler also works with any modern compiler toolchain thanks to the simplification of the architecture and the maintenance is much easier. Very handy new features, e.g, unicode support, optional records will be available on next release.

These all great things happen even without a full time job.

  • ReScript and OCaml benefit each other

We would like to see OCaml having a boom community and I am excited to see the upcoming multicore landed. When I see the new website is built using ReScript, I am very happy and would be happy to prioritize the feature request from them.

Why ReScript decides to grow as its own language is that the native backend and front-end are completely two different worlds. I am excited to see multicore landed in OCaml, but it does not have any impact over ReScript.

In the history of ReScript development, we don’t see major contributions from OCaml experts, but there’s great potential, ReScript has one of the highest quality to-JS compiler (thanks to OCaml and it keeps going), contributions are more than welcome, let’s work together to bring ML to more users.

10 Likes

For me, the important factor here is that the backend language market has almost reached a point where the languages and their ecosystems are commodities (how many times can we rewrite and port sinatra?). The frontend language market is still evolving, users are still eager to try out alternatives. If someone pushed a VC backed fork of Elm, or if ReScript got a huge burst of funding and its own ecosystem, I could picture one of these contenders getting up to 40% market share amongst a crowd of programmers who might be ambivalent to typed functional programming. Even basic tooling questions like webpack vs vite and esbuild vs swc vs babel, haven’t been settled yet.

On the backend, I think people felt similar excitement for the potential of Scala to overcome Java, when Scala started gaining momentum for a while.

As others have mentioned, I think OCaml also has a great shot at competing with esbuild and swc, if someone in OCaml was inspired to build a competitor to those tools.

In case what I said came out wrong:

Your achievements are astonishing.

My comment was a neutral observation. Anyway, I do not know much about the historical context, which compelled the project to take its current trajectory, to give a biased opinion.

And I commenting on the rationale of the internals of ReScript would look much like a hospital guard explaining what went wrong in a surgery.

Personally I have reservations about some of the non-technical aspects - need for a JavaScript-like syntax; marketing ReScript as a fast, fully typed JavaScript at the cost of eclipsing its other functional features - people have come away with an impression of ReScript = TypeScript NextVersion, but without its momentum and backing; and the apparent goal of taking over the JavaScript world - such a lofty objective may eventually burn the team out.

But those are just that – my personal disagreements. I would still recommend ReScript as one of the options to someone who is looking for a better frontend ecosystem.

Keep up the good work!

1 Like

that’s encroaching, isn’t it? Smacks of lock-in, but may be admittedly fashionable. Do (edit) one thing and do it right, on the other hand, is cooperative while naturally more complicated.

My thought is better phrased as ‘who wouldn’t feel attracted to that approach if they can make it happen?’

In the history of ReScript development, we don’t see major contributions from OCaml experts, but there’s great potential […]

This is a useful fact. However, if you want to attract people from OCaml to hack on your compiler in the future you need to attract them to a more modern code base. You didn’t address the fact that the rescript compiler and merlin based LSP backend is 4.06 era. I was hoping to a get a reaction regarding melange project also but you did not address that point too (see A short history of ReScript (BuckleScript) - #46 by sid )

So I think you have two choices here (both are fine IHMO. It depends on the tradeoffs you want to make)

(1) Maintain your totally independent direction. This gives you maximum freedom and autonomy to make changes anywhere in your language, compiler, tooling. The disadvantage is that ReScript is an island and the burden to do everything is on you. You don’t have others working on the compiler, it is only you.
(2) Hitch yourself back to the OCaml system in some way. My suggestion is to continue diverging your front end language to deal with the needs of Javascript but fuse in the rescript backend to OCaml trunk and submit any customizations to the OCaml project. This is the more tedious route – it requires you to create consensus, argue for your changes, submit PRs etc. This the route taken by mirage, multicore team. Things slow down but more people are looking at the code you write etc.

Seems like you have decided to go all in for (1). Nothing wrong with the strategy. All I’m saying that for many OCaml experts to get excited about working on the Rescript backend there needs to be some active connection to the current ocaml ecosystem. My guess is that OCaml developers would find working on 4.06 era code not very appealing.

Lastly, I notice that you keep stressing how fast Rescript is. No doubt that is a huge advantage you have. But beyond a point there are declining returns to this feature. By chopping off the ReasonML front end and substituting your own front end you gained 20% speed you say. However, the schism that created in the community you lost a lot of passionate advocates for the Reason/Rescript language, created uncertainty and disagreement. Will it be worth it in the long run? It possible that your decision resulted in a cleaner, better, faster code but was a net negative when it came to community in the immediate term. Will the technical factors triumph over the people factors? I don’t know.

However, what is done is done – looking forward you seem to ask the OCaml community to contribute to the rescript project (which is great BTW). All I’m saying is that you need to create a link to the current OCaml ecosystem in someway to incentivize the would be future contributor. The OCaml.org redesign using Rescript is not doubt a great vote of confidence in your project. You can create even more energy in the Rescript project by collaborating with OCaml in some way – I have already made my suggestions here above.

Lastly, thank you for engaging. Like I’ve repeated stated, the Rescript project has the right to pursue whichever strategy it likes. I appreciate the goals of your project and I wish Rescript succeeds beyond your wildest dreams.

3 Likes

Would it be possible to make ReScript a first-class citizen of the OCaml ecosystem, similar to ReasonML, by adopting and maintaining the changes to the intermediate language representation that enable such high quality JavaScript emission in the mainline OCaml compiler? The ReScript team can then focus on developing the ReScript language and the JavaScript emission backend module without having to constantly maintain and update a fork of the OCaml compiler.

+1. I too am advocating for this. See A short history of ReScript (BuckleScript) - #46 by sid

2 Likes

Hi,
Sorry, I did not go to details, my original post is in the hope to estabilish a friendship so that both ReScript and OCaml community support each other despite that they are not the same thing. I geninuely believe they will benefit each other in the long term.

You didn’t address the fact that the rescript compiler and merlin based LSP backend is 4.06 era.

FYI, we made our own LSP server. I believe it is a right decision in the long term.

By chopping off the ReasonML front end and substituting your own front end you gained 20% speed you say.

The speed up comes from type checking refactoring and removal of previous hacks.
Note we focus on not only fast compilation but also generating fast yet readable code.

Maintain your totally independent direction.

Yes, that’s the decision made. It is not as scary as you thought, it has been always the case that the whole toolchain is maintained by a couple of people since the beginning. Due to the recent simplification of the architecture, the maintainance overhead is even lower. We wish we could attract more contributors, but maintain our direction does not make anything worse.

All I’m saying is that you need to create a link to the current OCaml ecosystem in someway to incentivize the would be future contributor.

The heritage from OCaml is well acknowledged. We put the OCaml project in the beginning of acknowledgement section.

With regard to melange, I would not want to comment on it. It is a fork without any communitcation to us. You should make your own judgement that it is a sustainable technology or an interesting hack.

Last but the most important point: ReScript is a piece of software written in OCaml, I appreciate what OCaml gave me and hope it is a project that OCaml folks can be proud of.

I belive I expressed my ideas clearly, I will stop here.

4 Likes

@bobzhang I noticed that the vendored OCaml version that ReScript uses is now 4.10.3+dev0-2020-12-08. Does that mean ReScript can now be built with the stock OCaml compiler? That is pretty cool if true. Previously the ReScript branch of OCaml 4.06.1+rescript was too old to work natively on Apple M1.

My installed version of OCaml is 4.10.2 and it seems to build bsc.exe, bsb_helper.exe and rescript.exe without a problem.

1 Like

Yes, it should build pretty much with any version of modern ocaml compiler.
We are also thinking to port the dev build system to dune for easy contributions.

11 Likes

Would it be correct to think that ReScript is now separate language from OCaml that utilizes the OCaml compiler? My impression after reading this thread is that this is really about giving a good language to the web development community and less about allowing OCaml developers to program the browser with OCaml.

I guess most people on this message board are more interested in the latter, and there is some disappointment that ReasonML/ReasonScript/BuckleScript/ReScript has never really been that language, though it looked like it would be at one stage of development. I guess it’s back to Jsoo for that. :man_shrugging:

3 Likes

I guess it’s back to Jsoo for that. :man_shrugging:

Jsoo needs work for Ocaml 5.0 (aka multicore OCaml) – its future is not de-risked yet – see here

(I think something will happen eventually though on jsoo. There is already a lot of if investment in jsoo by various ocaml companies)

1 Like

You are right. Rescript is for people who appreciate ML type system && treat JS as the most important backend.

It does not have too much overlap with jsoo, this is always the case since the beginning.
I recommend people who have large existing OCaml code bases to stick with jsoo.

Rescript is for people who want to ship products on JS platform with optimal user experience. For example, if 10K bytes JS code size matters to you, you may have a look at Rescript.

7 Likes

I don’t think people should think about jsoo as at all risky. The plans for how to extend jsoo to support effects is not fully settled, but I think users can be highly confident that a solution for jsoo will be found. It’s just too important to too many users, Jane Street included. And the people who understand the details best are confident there are good solutions here.

y

16 Likes