Add more motivation to the intro #60

feihong · 2024-10-24T02:54:24Z

Addresses #58

davesnx · 2024-10-24T08:32:53Z

docs/intro/index.md

+sync[^1]. In the near future, it will be possible to write [universal React
+components](https://github.com/ml-in-barcelona/server-reason-react) that are
+performantly rendered on the server using OCaml.


I wouldn't say "I the near future", it's already possible. It's just not polished. I would explain within the previous sentence: you can write a full-stack application (sharing types, components rendered on the server, etc etc)

How about:

If the backend is also written in OCaml,
you can share types between the frontend and backend, ensuring that they stay in
sync[^1]. It's even possible to write universal React
components that are
rendered on the server with the performance of native code[^2].

The [^2] footnote will explain that it's not yet polished.

That's a better phrasing indeed

Rephrased in 8ca7939

davesnx · 2024-10-24T08:33:55Z

docs/intro/index.md

+All that said, how does OCaml compare against other prominent compile-to-JS
+languages?
+
+**TypeScript** is a gradually-typed superset of JavaScript. It is easier to
+learn and adopt, but is less type-safe than OCaml and all other langues on this
+list. TypeScript doesn't support pattern matching at the language level.
+
+**ReScript** is very similar to OCaml, even at the syntax level. Its
+RescriptReact library is roughly equivalent to our ReasonReact library. The main
+differences are that ReScript's only compilation target is JS, and it lacks the
+metaprogramming features of OCaml, so you lose the ability to, say, [embed CSS
+styles directly into your code](https://styled-ppx.vercel.app/).
+
+**Elm** is similar to OCaml but leans much more strongly towards pure functional
+programming. It cannot use React but comes with its own framework. It has many
+fewer options for JS interop. Even though Elm compiles to JS, it can't be used
+for backend development, even on Node.

-This is a project-based, guided introduction to Melange and its ecosystem.
+**F#** is a fullstack language similar to OCaml and is strongly aligned with the
+.NET ecosystem. F# has good support for functional programming and zero-cost
+interop with C#. Feliz is an F# wrapper library for React that doesn't support
+JSX.
+
+**Kotlin** is a type-safe fullstack language strongly associated with the
+Compose Multiplatform UI framework. Kotlin-react is a Kotlin wrapper library for
+React which doesn't support JSX. Kotlin has some features in common with OCaml,
+but doesn't have pattern matching.
+
+**Dart** is a type-safe fullstack language strongly associated with the Flutter
+UI framework, which supports compiling UI apps to mobile, desktop, and browser
+environments. There's no Dart wrapper library for modern, functional React
+components.
+
+**OCaml** has another JS transpiler called js_of_ocaml. Unlike Melange,
+js_of_ocaml prioritizes OCaml compatibility over JavaScript interop.
+
+As you can see, each compile-to-JS language has its own design goals, which
+dictate its strengths and weaknesses relative to OCaml and Melange.


I would move this into a separate section or even in the melange documentation

The language comparison section was added in response to #58 and also another reader who responded to me via DM. But I agree it makes sense to add it to Melange docs as well.

davesnx · 2024-10-24T08:34:35Z

docs/intro/index.md

+that translates OCaml to human-readable JavaScript and built-in language
+constructs for zero-cost interoperation with JavaScript.
+
+## Why OCaml?


Same discussion as ever, but "Why OCaml?" when you will write the book in reason is strange, confusing

It seems to me that most of the benefits of Melange come from OCaml, and the book does teach OCaml (using Reason syntax).

Oh wait, do you mean Melange in the sense of the subset of OCaml language supported by Melange?

To add my 2 cents: It might be beneficial to just add a quick note that communicates that:

Ocaml = general purpose programming language developed in the 90s (and from my understanding, derived from ML
ReasonML = a set of Ocaml extensions/different way of writing OCaml (this is my understanding as someone with lots of functional JavaScript experience, but not a whole lot of ML experience)

Also note that while we are talking about Ocaml here, the reader can expect to see a lot more ReasonML later.

feihong · 2024-10-24T15:12:54Z

docs/intro/index.md

+that translates OCaml to human-readable JavaScript and built-in language
+constructs for zero-cost interoperation with JavaScript.
+
+## Why OCaml?


It seems to me that most of the benefits of Melange come from OCaml, and the book does teach OCaml (using Reason syntax).

feihong · 2024-10-24T15:16:31Z

docs/intro/index.md

+sync[^1]. In the near future, it will be possible to write [universal React
+components](https://github.com/ml-in-barcelona/server-reason-react) that are
+performantly rendered on the server using OCaml.


How about:

If the backend is also written in OCaml,
you can share types between the frontend and backend, ensuring that they stay in
sync[^1]. It's even possible to write universal React
components that are
rendered on the server with the performance of native code[^2].

The [^2] footnote will explain that it's not yet polished.

feihong · 2024-10-24T15:17:47Z

docs/intro/index.md

+
+**OCaml** has another JS transpiler called js_of_ocaml. Unlike Melange,
+js_of_ocaml prioritizes OCaml compatibility over JavaScript interop.
+


Originally I had one paragraph for Rust here, but not sure if it's really in the same space as it compiles to WebAssembly and not normal JS. Should I bring it back?

Is a comparison to Gleam worthwhile?

And PureScript since it was mentioned in the issue?

@psb Add comparison to Gleam in 4d8e896

I haven't heard much about PureScript in recent years, so I don't think it meets the criteria of "prominent compile-to-JS language".

feihong · 2024-10-24T15:19:52Z

docs/intro/index.md

+All that said, how does OCaml compare against other prominent compile-to-JS
+languages?
+
+**TypeScript** is a gradually-typed superset of JavaScript. It is easier to
+learn and adopt, but is less type-safe than OCaml and all other langues on this
+list. TypeScript doesn't support pattern matching at the language level.
+
+**ReScript** is very similar to OCaml, even at the syntax level. Its
+RescriptReact library is roughly equivalent to our ReasonReact library. The main
+differences are that ReScript's only compilation target is JS, and it lacks the
+metaprogramming features of OCaml, so you lose the ability to, say, [embed CSS
+styles directly into your code](https://styled-ppx.vercel.app/).
+
+**Elm** is similar to OCaml but leans much more strongly towards pure functional
+programming. It cannot use React but comes with its own framework. It has many
+fewer options for JS interop. Even though Elm compiles to JS, it can't be used
+for backend development, even on Node.

-This is a project-based, guided introduction to Melange and its ecosystem.
+**F#** is a fullstack language similar to OCaml and is strongly aligned with the
+.NET ecosystem. F# has good support for functional programming and zero-cost
+interop with C#. Feliz is an F# wrapper library for React that doesn't support
+JSX.
+
+**Kotlin** is a type-safe fullstack language strongly associated with the
+Compose Multiplatform UI framework. Kotlin-react is a Kotlin wrapper library for
+React which doesn't support JSX. Kotlin has some features in common with OCaml,
+but doesn't have pattern matching.
+
+**Dart** is a type-safe fullstack language strongly associated with the Flutter
+UI framework, which supports compiling UI apps to mobile, desktop, and browser
+environments. There's no Dart wrapper library for modern, functional React
+components.
+
+**OCaml** has another JS transpiler called js_of_ocaml. Unlike Melange,
+js_of_ocaml prioritizes OCaml compatibility over JavaScript interop.
+
+As you can see, each compile-to-JS language has its own design goals, which
+dictate its strengths and weaknesses relative to OCaml and Melange.


The language comparison section was added in response to #58 and also another reader who responded to me via DM. But I agree it makes sense to add it to Melange docs as well.

jchavarri

It's looking great.

A note on the comparison section, it might sound a bit defensive, maybe some wording like usages of "but" ("TS is easier, but...", "Elm is similar, but..."), and also some extended usage of adjectives that can be vague ("much more strongly", "many fewer options"...) contribute to that?

Maybe this section should show alternatives and why one would pick them up (rather than focusing on what they're missing).

If the goal is to show what things they're missing (pattern matching, React integration, zero cost bindings, JSX) it might be better to create a table instead.

jchavarri · 2024-10-25T06:13:51Z

docs/intro/index.md

+
+OCaml codebases scale well both in terms of quantity of lines and number of
+contributors. The sound type system helps to prevent ambiguous behavior in your
+program---if it compiles, it runs. OCaml and React (via


The "if it compiles, it runs" is a bit confusing because TypeScript also "runs if it compiles" 😄 What about

Suggested change

program---if it compiles, it runs. OCaml and React (via

program---if it compiles, it runs without runtime errors. OCaml and React (via

?

Fixed in 8ca7939

jchavarri · 2024-10-25T06:14:33Z

docs/intro/index.md

+languages?
+
+**TypeScript** is a gradually-typed superset of JavaScript. It is easier to
+learn and adopt, but is less type-safe than OCaml and all other langues on this


Suggested change

learn and adopt, but is less type-safe than OCaml and all other langues on this

learn and adopt, but is less type-safe than OCaml and all other languages on this

Fixed in #60

jchavarri · 2024-10-25T06:18:25Z

docs/intro/index.md

+**ReScript** is very similar to OCaml, even at the syntax level. Its
+RescriptReact library is roughly equivalent to our ReasonReact library. The main


Suggested change

**ReScript** is very similar to OCaml, even at the syntax level. Its

RescriptReact library is roughly equivalent to our ReasonReact library. The main

**ReScript** is very similar to OCaml, even at the syntax level. Its

rescript-react bindings are roughly equivalent to Melange reason-react bindings. The main

Changed in #60

jchavarri · 2024-10-25T06:19:23Z

docs/intro/index.md

+metaprogramming features of OCaml, so you lose the ability to, say, [embed CSS
+styles directly into your code](https://styled-ppx.vercel.app/).


Styled-ppx supports ReScript, so I would rather mention the ability to write universal components as the main benefit or Melange + ReasonReact.

Deleted metaprogramming mention in #60

jchavarri · 2024-10-25T06:21:14Z

docs/intro/index.md

+environments. There's no Dart wrapper library for modern, functional React
+components.
+
+**OCaml** has another JS transpiler called js_of_ocaml. Unlike Melange,


There's the Melange for X developers page that has a jsoo section, not sure if worth mentioning.

Also includes subsections about ReScript and TypeScript.

Add links to ReScript and jsoo detailed comparisons in 8ca7939

Add link to detailed TypeScript comparison in e54eb1f

jchavarri · 2024-10-25T06:21:47Z

docs/intro/index.md

+components.
+
+**OCaml** has another JS transpiler called js_of_ocaml. Unlike Melange,
+js_of_ocaml prioritizes OCaml compatibility over JavaScript interop.


I'd also mention that the story to use React is much more stable and tested in Melange than in jsoo.

Add this detail in d36abdf

jchavarri · 2024-10-25T06:25:43Z

docs/intro/index.md

+metaprogramming features of OCaml, so you lose the ability to, say, [embed CSS
+styles directly into your code](https://styled-ppx.vercel.app/).
+
+**Elm** is similar to OCaml but leans much more strongly towards pure functional


Suggested change

**Elm** is similar to OCaml but leans much more strongly towards pure functional

**Elm** is similar to OCaml. It leans strongly towards pure functional

Changed in #60

jchavarri · 2024-10-25T06:29:57Z

docs/intro/index.md

+programming. It cannot use React but comes with its own framework. It has many
+fewer options for JS interop. Even though Elm compiles to JS, it can't be used
+for backend development, even on Node.


Suggested change

programming. It cannot use React but comes with its own framework. It has many

fewer options for JS interop. Even though Elm compiles to JS, it can't be used

for backend development, even on Node.

programming. It has fewer options for JS interop and cannot use React but comes with

its own framework. Elm can't be used for backend development, even on Node.

"It cannot use React but comes with its own framework".

It's more like: "Elm treats JavaScript as unsafe, with possibility to interact with it via ports. Integrations like React or Melange FFI aren't possible"

Changed in #60

Use can use Elm on the backend: lamdera & elm-pages, but I don't think you can use node apis.

never understood how lamdera or elm-pages run in the backend. I asked a few times here and there and didn't get a decent answer. Just offtopic, but always curious

@psb I perused lamdera and elm-page sites but couldn't get a clear idea of how they work at all, so I'm hesitant to include it in the comparison

davesnx · 2024-10-25T08:09:19Z

docs/intro/index.md

+**TypeScript** is a gradually-typed superset of JavaScript. It is easier to
+learn and adopt, but is less type-safe than OCaml and all other langues on this


I would try to be more expressive on comparing with TypeScript.

TypeScript is a gradually-typed superset of JavaScript. It's easier to
learn and adopt. His design, following closely JavaScript, brings a few footguns, like any, "as" casting, and ts-nocheck (to say a few) becoming less type-safe than OCaml.

Added in #60

feihong · 2024-11-01T03:16:14Z

@psb What do you think?

psb · 2024-11-01T14:59:32Z

docs/intro/index.md

+.NET ecosystem. F# has good support for functional programming and zero-cost
+interop with C#. Feliz is an F# wrapper library for React that doesn't support
+JSX.
+


I think you can use jsx in Fable/Feliz: https://fable.io/blog/2022/2022-10-12-react-jsx.html , it's just that most people use the elm like syntax.

I took a look at JSX in Fable/Feliz, but the usage doesn't seem ergonomic to me (implemented using string templates). Probably just my opinion, but I don't think it qualifies as "JSX".

psb · 2024-11-01T16:13:44Z

I think you might have to go deeper in comparing it to TypeScript. When you watch a video of someone doing TS or React in TS it is easy to think that TS is good enough or type safe enough, so I don't think words are going to convince someone to switch, especially since using Melange is not a trivial matter - someone has to learn Reason/OCaml, dune, melange, interop, and maybe even functional programming for the first time. I think code comparisons and concrete examples will be more convincing reasons to switch, e.g.,:

showing code that type checks in TS but actually causes a bug, and how it would have been caught by Reason
showing how interop can make third party code safe
automatic decoders and encoders compared to something like zod
(validators?)
type safe css
build times on large codebases with real numbers
no need to keep reloading the editor on large codebases
monorepos
match statement exhaustiveness vs switch statements or if else blocks
type safe routing (frontend and across to an ocaml backend)
errors as values compared to try/catch
react ssr speed compared to a node backend
any other examples that show off Reason/ReasonReact capabilities compared to TS

Some of this may overlap with Reason docs but I think that is okay. You really have to make someone think 'wow!' and really want to explore it further; otherwise, it will seem that TS is just good enough.

Testimonials from production users can also go a long way in convincing people to try it out.

This might have to it's own section if you think it is worth doing.

davesnx · 2024-11-14T17:11:19Z

docs/intro/index.md

+All that said, how does OCaml compare against other prominent compile-to-JS
+languages?
+
+**TypeScript** is a gradually-typed superset of JavaScript. It's easier to learn
+and adopt because its design highly emphasizes compatibility with JavaScript.
+This brings a few footguns, such as `any`, `as` casting, `ts-nocheck` etc,
+making it less type-safe than OCaml (and all the other languages on this list)[^3].
+
+- Zero-cost JS interop? Yes
+- Can use with React? Yes
+- Supports JSX? Yes
+- Pattern matching? No
+- Can use on server? Yes, via Node.
+
+**ReScript** is very similar to OCaml, even at the syntax level. The main
+difference is that ReScript's only compilation target is JS[^4].
+
+- Zero-cost JS interop? Yes
+- Can use with React? Yes, via [@rescript/react](https://github.com/rescript-lang/rescript-react), which is roughly equivalent to
+  Melange's ReasonReact bindings.
+- Supports JSX? Yes
+- Pattern matching? Yes
+- Can use on server? Yes, via Node.
+
+**Elm** is similar to OCaml. It leans strongly towards pure functional
+programming.
+
+- Zero-cost JS interop? No. Elm treats JavaScript as unsafe, interacting with JS
+  via ports (more like message passing than traditional FFI). Ergonomic
+  integration with React and other libraries isn't possible.
+- Can use with React? No. Elm has its own framework with some similar concepts.
+- Supports JSX? No
+- Pattern matching? Yes
+- Can use on server? No
+
+**F#** is a fullstack language similar to OCaml and is strongly aligned with the
+.NET ecosystem.
+
+- Zero-cost JS interop? Probably
+- Can use with React? Yes. [Feliz](https://github.com/Zaid-Ajaj/Feliz) is an F#
+  wrapper library for React.
+- Supports JSX? No. Feliz uses ordinary function call syntax for render logic.
+- Pattern matching? Yes
+- Can use on server? Yes, via .NET or Node.
+
+**Gleam** is a fullstack language similar to OCaml which is aligned with the
+BEAM ecosystem.
+
+- Zero-cost JS interop? No, but Gleam's JS compilation target is relatively new,
+  so it may become more optimized in the future.
+- Can use with React? Yes, via [redraw](https://github.com/ghivert/redraw) and [react-gleam](https://github.com/brettkolodny/react-gleam).
+- Supports JSX? No
+- Pattern matching? Yes


I don't see the point of this section, this is a book of Reason and Melange.

Let's encourage people to read about comparisons in the melange documentation or a blog post.

I'd kind of lean this way too. It reads a bit like a sales pitch. Maybe at a minimum, cut down on a few of the alternatives.

davesnx · 2024-11-14T17:12:05Z

docs/intro/index.md

-Correct + Efficient + Beautiful](https://cs3110.github.io/textbook/), which
-teaches the language from the ground up and goes much deeper into its features.
+[ReasonReact][reasonreact]. You do not need to know OCaml[^6]---we'll slowly
+introduce the basics of the language throughout the tutorial. That said, a good


probably the audience is a bit "informed" about FP

feihong · 2024-11-14T17:34:34Z

@psb

I think you might have to go deeper in comparing it to TypeScript. When you watch a video of someone doing TS or React in TS it is easy to think that TS is good enough or type safe enough, so I don't think words are going to convince someone to switch, especially since using Melange is not a trivial matter - someone has to learn Reason/OCaml, dune, melange, interop, and maybe even functional programming for the first time. I think code comparisons and concrete examples will be more convincing reasons to switch

I think the scope of the book is to teach the reader how to use Melange. Motivating them to do so should be the work of blog posts, conference talks, testimonials, i.e. the work of the wider community.

wojonet · 2024-11-14T23:07:44Z

docs/intro/index.md

+that translates OCaml to human-readable JavaScript and built-in language
+constructs for zero-cost interoperation with JavaScript.
+
+## Why OCaml?


To add my 2 cents: It might be beneficial to just add a quick note that communicates that:

Ocaml = general purpose programming language developed in the 90s (and from my understanding, derived from ML
ReasonML = a set of Ocaml extensions/different way of writing OCaml (this is my understanding as someone with lots of functional JavaScript experience, but not a whole lot of ML experience)

Also note that while we are talking about Ocaml here, the reader can expect to see a lot more ReasonML later.

wojonet · 2024-11-14T23:08:55Z

docs/intro/index.md

+OCaml codebases scale well both in terms of quantity of lines and number of
+contributors. The sound type system helps to prevent ambiguous behavior in your
+program---if it compiles, it runs without runtime errors. OCaml and React (via
+[ReasonReact][reasonreact]) are an effective, FP-friendly combination for


A quick note on how ReasonReact relates to OCaml/ReasonML - it's not clear to me. May not be important at this point, but just a thought.

wojonet · 2024-11-14T23:10:14Z

docs/intro/index.md

+This brings a few footguns, such as `any`, `as` casting, `ts-nocheck` etc,
+making it less type-safe than OCaml (and all the other languages on this list)[^3].
+
+- Zero-cost JS interop? Yes


Maybe for each of these lists, a quick "Pros and Cons"

wojonet · 2024-11-14T23:12:20Z

docs/intro/index.md

+All that said, how does OCaml compare against other prominent compile-to-JS
+languages?
+
+**TypeScript** is a gradually-typed superset of JavaScript. It's easier to learn
+and adopt because its design highly emphasizes compatibility with JavaScript.
+This brings a few footguns, such as `any`, `as` casting, `ts-nocheck` etc,
+making it less type-safe than OCaml (and all the other languages on this list)[^3].
+
+- Zero-cost JS interop? Yes
+- Can use with React? Yes
+- Supports JSX? Yes
+- Pattern matching? No
+- Can use on server? Yes, via Node.
+
+**ReScript** is very similar to OCaml, even at the syntax level. The main
+difference is that ReScript's only compilation target is JS[^4].
+
+- Zero-cost JS interop? Yes
+- Can use with React? Yes, via [@rescript/react](https://github.com/rescript-lang/rescript-react), which is roughly equivalent to
+  Melange's ReasonReact bindings.
+- Supports JSX? Yes
+- Pattern matching? Yes
+- Can use on server? Yes, via Node.
+
+**Elm** is similar to OCaml. It leans strongly towards pure functional
+programming.
+
+- Zero-cost JS interop? No. Elm treats JavaScript as unsafe, interacting with JS
+  via ports (more like message passing than traditional FFI). Ergonomic
+  integration with React and other libraries isn't possible.
+- Can use with React? No. Elm has its own framework with some similar concepts.
+- Supports JSX? No
+- Pattern matching? Yes
+- Can use on server? No
+
+**F#** is a fullstack language similar to OCaml and is strongly aligned with the
+.NET ecosystem.
+
+- Zero-cost JS interop? Probably
+- Can use with React? Yes. [Feliz](https://github.com/Zaid-Ajaj/Feliz) is an F#
+  wrapper library for React.
+- Supports JSX? No. Feliz uses ordinary function call syntax for render logic.
+- Pattern matching? Yes
+- Can use on server? Yes, via .NET or Node.
+
+**Gleam** is a fullstack language similar to OCaml which is aligned with the
+BEAM ecosystem.
+
+- Zero-cost JS interop? No, but Gleam's JS compilation target is relatively new,
+  so it may become more optimized in the future.
+- Can use with React? Yes, via [redraw](https://github.com/ghivert/redraw) and [react-gleam](https://github.com/brettkolodny/react-gleam).
+- Supports JSX? No
+- Pattern matching? Yes


I'd kind of lean this way too. It reads a bit like a sales pitch. Maybe at a minimum, cut down on a few of the alternatives.

wojonet · 2024-11-14T23:15:21Z

docs/intro/index.md

+introduce the basics of the language throughout the tutorial. That said, a good
+complement to this guide is [OCaml Programming: Correct + Efficient +
+Beautiful](https://cs3110.github.io/textbook/), which teaches the language from
+the ground up and goes much deeper into its features.


I really like the external resources for further reading!

Add more motivation to the intro

db8c414

feihong mentioned this pull request Oct 24, 2024

Intro should explain what Melange/Reason/Ocaml are and why they're worth learning #58

Open

davesnx reviewed Oct 24, 2024

View reviewed changes

feihong commented Oct 24, 2024

View reviewed changes

feihong marked this pull request as ready for review October 24, 2024 16:33

feihong requested a review from jchavarri October 24, 2024 16:33

jchavarri reviewed Oct 25, 2024

View reviewed changes

davesnx reviewed Oct 25, 2024

View reviewed changes

feihong added 3 commits October 31, 2024 21:39

Fixes in language comparison section

8ca7939

Add link to detailed TypeScript comparison

e54eb1f

Mention stability of reason-react vs jsoo-react

d36abdf

feihong requested review from jchavarri and davesnx November 1, 2024 03:15

psb reviewed Nov 1, 2024

View reviewed changes

feihong added 2 commits November 8, 2024 23:06

Add comparison with Gleam

4d8e896

Add admonition to file an issue if there are inaccuracies

a79b2db

davesnx reviewed Nov 14, 2024

View reviewed changes

wojonet reviewed Nov 14, 2024

View reviewed changes


		OCaml has another JS transpiler called js_of_ocaml. Unlike Melange,
		js_of_ocaml prioritizes OCaml compatibility over JavaScript interop.

	program---if it compiles, it runs. OCaml and React (via
	program---if it compiles, it runs without runtime errors. OCaml and React (via

	learn and adopt, but is less type-safe than OCaml and all other langues on this
	learn and adopt, but is less type-safe than OCaml and all other languages on this

		ReScript is very similar to OCaml, even at the syntax level. Its
		RescriptReact library is roughly equivalent to our ReasonReact library. The main

		metaprogramming features of OCaml, so you lose the ability to, say, [embed CSS
		styles directly into your code](https://styled-ppx.vercel.app/).

	Elm is similar to OCaml but leans much more strongly towards pure functional
	Elm is similar to OCaml. It leans strongly towards pure functional

		TypeScript is a gradually-typed superset of JavaScript. It is easier to
		learn and adopt, but is less type-safe than OCaml and all other langues on this

Add more motivation to the intro #60

Are you sure you want to change the base?

Add more motivation to the intro #60

Conversation

feihong commented Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jchavarri left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feihong commented Nov 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

psb commented Nov 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feihong commented Nov 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

feihong commented Oct 24, 2024 •

edited

Loading