ReScript Office Hours #4

Hi everyone!

We want to keep up the pace and announce our next ReScript Office Hour!

What are ReScript Office Hours?

This is a remote event where everyone in the community to talk about ReScript. This time will be casual, no concrete items to be discussed, we want to hear your feedback in general to prioritize things for the roadmap of 2021.

When and how to join?

Dec 23 / 7PM - 8PM (GMT +8)
Join Zoom Meeting
https://us04web.zoom.us/j/75490878460?pwd=UDJSRE9hTUVKL0xkT1pwbjU4Vlljdz09

Meeting ID: 754 9087 8460
Passcode: P6dLD0

See you soon & Happy Holidays!

10 Likes

My timezone is GMT+1

1 Like

Hi Hongbo! GMT+3 here.

1 Like

My timezone is GMT+1, too.

1 Like

Hello from Chicago: GMT-6

1 Like

You can select your timezone here if you wish:

My timezone (UTC +/-) is:
  • -11 to -9
  • -8
  • -7
  • -6
  • -5
  • -4
  • -3
  • -2
  • -1
  • 0
  • +1
  • +2
  • +3
  • +4
  • +5
  • +6
  • +7
  • +8
  • +9
  • +10 to +14

0 voters

2 Likes

Hi all, thanks for the participation, it seems that the timezone is evenly distributed, so that I will take the same time as last office hour
Dec 23/ 7PM-8PM (GMT+8 Timezone)
The link fo joining the conference is updated in the main thread.
If you cannot make it, you can ask questions here, we will answer them during the meeting.

1 Like

Here is a more comfortable overview (hover over the datetimes to see common local times):
2020-12-23T11:00:00Z → 2020-12-23T12:00:00Z

4 Likes

The edited OP says December 3, not 23, that was confusing for a moment :joy:

Hi, for people who can not make it, we have a draft of to-do list for the next year roadmap https://docs.google.com/document/d/1hiuYDEix312gUV9Jscb8akRhas4USVr33LMhd0J0RoI/edit?usp=sharing
You are welcome to leave comments here

4 Likes

Excellent, thanks for sharing this here too @Hongbo! Dynamic imports are mentioned in the doc (I also started a thread about that a few days ago) - for those of us who won’t be able to attend the office hours, could you expand a bit on the plan around dynamic imports?

Gonna summarize it, because it was a quick note in the google doc:
@bloodyowl asked if there is any work done regarding making dynamic imports easier.

Quick answer: There is currently no active tasks regarding better dynamic import support, but it might be worth looking into it soon.

Sorry I missed it, the timing close to Christmas just wasn’t good for me.

Separating the stdlib from the compiler isn’t in the doc, but it was in the 2020 roadmap, what’s happening with that?

For this particular issue, we addressed the most pain point: the installation time. Now it’s just a couple of seconds to install bs-platform which is actually smaller than an average npm repo, in that case, add bs-platform to your consumer sounds not that bad.

So the real benefit of separating stdlib from compiler is just the package size, it is not a very big win in my opinion. There are some downsides when separating the compiler from stdlib though, user has to install 2 packages, we are unclear how to ensure package manager to lock them into a single version. We need more benefit to justify such change

I’m sorry but you seem to have misunderstood the request for a separate stdlib. Size is only a small part of it. I didn’t realise this until now, but your summary issue about it missed one of the original issues:

This issue very clearly states the reason I and others have requested this for years now. We want to publish compiled JS libraries from ReScript that depend on just the stdlib JS files. It is nice that bs-platform no longer compiles OCaml, but there’s still over a hundred megabytes of things that are not relevant to a library published in this way.

So yes size matters but there are plenty of other factors that matter for projects where the node_modules folder needs to be published; of the top of my head I can think of security as a big one, uploading unnecessary binaries is never a good idea, and bandwidth / hosting costs are another. In Javier’s specific example creating a vscode extension means the binaries must be uploaded to Microsoft, who might have a problem with it if the extension becomes popular while including a hundred megabytes of stuff that isn’t used.

I will admit the vast majority of ReScript users today don’t need this. They’re building ReScript applications or libraries designed to integrate into ReScript applications. However in terms of the wider JS community that is quite limiting, and I think being able to publish a library for JS users without depending on the full bs-platform is a good goal to have.

4 Likes

Sorry, I missed the event, too, and I also have a question: What is the status of the monorepo support now? My understanding is that with 8.4.2, bsb -make-world already (re)compiles everything it should, but still needs to be reinvoked manually because file watching is not there yet.

Is that correct? If so, when can we expect a version with monorepo support including file watching? (I didn’t see that in the roadmap at all.)

Hi, the roadmap is not an exhaustive to-do list.
With regard to your question, the thing is that “file watching” is completely decoupled with the build process so this can be done in the user land without any performance penalty. We will keep this on the radar