Adding conditional compilation flags?

[JoelVerm]

I just discovered Gleam and I love it! At the moment, I'm trying to create something like a full-stack web framework for Gleam. It's basically a backend to glare with some additions.

Currently I have the frontend and backend in different gleam projects. You could then copy the build output from the frontend to be served by the backend. But because these are different projects you can't have common types (for example). So if you want to send something to the client you would need to define one type twice.

The idea

My idea is to add an attribute that works the same as @target but that works with flags. This way, you could specify at compile time what code would get compiled, so in my case the server or client. How this would look:

import gleam/io

fn common(a) {
  a + 5
}

@flag("server")
fn useful_function_name() {
  common(1) |> io.println
}

@flag("client")
fn another_function_name() {
  common(23) |> io.println
}

And then build with gleam build --flag=server

Why not just @target

Because most web hosting providers use a javascript runtime only, or have a much higher pricing for docker containers. By using @flag you can compile the server for javascript as well and still have one codebase.

It's just an idea

As I said, I'm fairly new to Gleam, so there may be a way to do this already. If there isn't, I'm sure my idea can be improved a lot, so please share some ideas, and maybe I can learn something in the process 😅

[lpil]

Hello! One would normally do this by having multiple packages in one repo that import each other. e.g. "frontend", "backend", and "shared". What would this proposal enable that that does not?

[JoelVerm]

Hi, the thing I would use it for is to have one single file for both the client and the server, just like next.js and similar web frameworks do it. I'm currently working on a prototype using the @target attribute and there the index.gleam file works like this (in short):

import glade.{html, server_signal}
import glare.{signal, text}
import glare/element.{button, header, p}
import glare/event.{onclick}
import glare/property.{class, font_family, size}
import gleam/io

const count_signal = glade.Signal(0, "count")

@target(javascript)
pub fn client() {
  let #(count, set_count) = server_signal(count_signal)

  html([
    header([
      p([text("Title")])
      |> font_family("Arial")
      |> size("1.5rem")
      |> class("title"),
    ]),
    p([text("count: "), signal(count)]),
    button([text("click me")])
      |> onclick(fn() {
      io.println("clicked")
      set_count(count() + 1)
    }),
  ])
}

@target(erlang)
pub fn server() {
  let #(on_count, set_count) = server_signal(count_signal)

  use count <- on_count
  set_count(count + 1)
}

However, the @flag attribute could also be used really well to define specific functions for debugging, so you could just pass the "debug" flag to enable logging or debugging for the entire app. It could also be used for compile time feature flags for example.

[lpil]

Given you can do this with path deps as I described what would be the advantage? Seems like it'd be a second way to do the same thing but more complex and with slower compile times.

[JoelVerm]

Yeah that's probably true, it's mostly for conciseness and easier to find code, so you don't need as many nested folders (because of multiple projects) and the server code is easier to find without looking in a separate project. But I'm really not familiar with the compiler itself so if it makes compile times a lot slower it would be a really bad idea 😅.

Right now I'll finish my prototype and post a github link here, that would be more helpful than my bad English I think 😅

[JoelVerm]

I've made my web framework and it works! It currently has to use erlang for the backend, but it works really well. The GitHub is https://github.com/JoelVerm/meadow if you'd like to check it out! The framework isn't finished yet, but it's in a working state ;)