We have static #programming languages that are both adequate for the server-side and can target the client-side (Javascript, WASM, native, etc), such as #Scala, #Kotlin, #Rust, #FSharp, #Typescript.

The biggest advantage of using the same language is that you can share code, starting with the data models, alongside serialization, and parsing/validation rules. The API can thus be easily kept in sync, and a server-side test is also relevant on the client-side.

@alexelcu
Indeed so, I chose #Scala3 for SWIM :
https://swim.benmatthews.eu
as I can write a complex society-climate #model, complex web GUI, and handle many historical datasets, all in one language - and I'm amazed how robustly #scalajs works for this. This is - so far - a one-man project. However individuals can keep coding longer than fashions in tech, or even mega corporations. Scala needs a broader influx, such examples of science code can help show python is not the only option.
Scalable World Interactive Model

@benjhm @jasmith Your project looks great and quite an inspiration! I have an open-source educational computing project that I have been thinking about for years and I finally want to get started. #scala 3 + #scalajs would be an excellent fit.

Scala 2 was my primary server-side language from 2009-2018. Two moderately large systems are still in production. I am learning what is new in Scala 3.

Can you recommend a SPA framework and a back-end service framework licensed for open-source release?

@jasmith
Hi Jonathon,
Thanks for encouraging words.
Currently, SWIM uses no frameworks (my own scala code makes svg plots), and no back-end - the web version you see just calculates in the browser (try disconnecting after it loaded, you can still change params and see plots adjust). This enables quick interactivity. However use of scala offers the potential for some science-modules to shift relatively easily to server side if they evolved to become more data-intensive.

@benjhm

I am hoping to build in some social features for small groups. Multiple people interacting with shared systems and spatial models. The model would run in the client but a server would receive and re-broadcast events representing user actions. Models + views in each person’s browser but synchronized.

A single language for server and client would make it easy for the server to maintain a live copy of the state. New users could “tune in” by downloading that copy and pulling missed events