Choose front-end tech stack

[pmoieni]

from the discussion we've made till now, turns out the vanilla TypeScript and HTML files have the upper hand over other web technologies. but we haven't still heard the opinions of all of the members about the tech stack that they are most comfortable working with.
the nature of this project forces us to be more front-end oriented and that doesn't mean we need to be more TypeScript oriented too. most likely we'll do the heavy lifting using WASM code which will be written in Golang that also has a built-in WASM compiler. for me using the vanilla TypeScript code with Vite is enough but let's hear what others think.

Share your ideas.

[harveysanders]

I think before we pick a stack, we may need to clearly define what the frontend looks like and does. Should we use this issue for that discussion or create a new one?

[pmoieni]

@harveysanders no. here is good.

[harveysanders]

+1 for typescript and vite though 😎

[adoublef]

regarding the FE, we will be supporting large screen devices (like PCs and Laptops), I presume smaller devices are out the equation given we need an additional midi controller for interactivity with the application?

If so, then I would probably opt for Preact/Svelte. Vanilla just isn't that expressive and boilerplate heavy when trying to prototype.

Also regarding WASM, have we looked into the Vite plug-ins currently? how is the support for those.

[adoublef]

An argument is to use JS and import urls avoiding needing to have node in the project whatsoever.

Given the FE is almost purely just design with not much logic, pure JS with import urls could also be an option. Con here is that importing WASM now is a bit more boilerplate than Vite

[adoublef]

Are we hosting the FE on a separate server or are we serving everything from within the Go application?

[pmoieni]

I think a separate server for the client is far better than running them on the same port. I mean separate ports, not separate servers though.

At least it increases the security of the whole app.

[adoublef]

separate ports would be separate servers though? Or do you mean we wouldn't use a different hosting site and rather host our FE files with Go (via a FileServer instance)?

[harveysanders]

I really think we should keep this simple to start. I don't really see an issue with serving the client application from the same server. If there is a need to break out the static server from the application server in the future, we can slap Nginx or something in front as a reverse proxy and a static server. Initially though, my vote is to keep it simple.

[adoublef]

so if that is the case, are we using a front-end framework and compiling (presuming we want to use TypeScript) to JS/HTML? If so is there one we would want to use? I notice above people are set on TS+vite, for development. Just whether vanilla TS or a library like Preact/Solid/Svelte before we compile to static files

[pmoieni]

I tried to build a front-end just for testing with TS and vite and it's really hard to make components and update variables dynamically. Although the only option we have is to write html as strings using innerHTML in typescript files which won't have any syntax highlighting and error checking.
I'll highly recommend using a framework for this task. Doesn't matter which one TBH.

[hansvb]

Personally I'm focused on having a CLI/TUI-client with the Bubbletea-framework.
As for browser front-end, I'm still a sucker for trying https://elm-lang.org/

[adoublef]

I would not be mad at using Elm as I have been learning quite a bit of Haskell recently. If we were to use TS, then I would probably say Svelte as that can compile to static files.

[adoublef]

seems there is a library for using web audio api with Elm. And scss.

Con with Elm is @pmoieni would need to port their note-tuner to work with Elm and I am unsure how that works

[hansvb]

Yeah, ELM is a bit of a stretch because there is less variety and choice than in the (HUGE) javascript-ecosystem. But that could also be considered a positive since there is maybe TOO much Javascript 😉
But what could be especially interesting is that https://github.com/charmbracelet/bubbletea actually uses (i.e. is inspired by) the ELM Architecture (Model / View /Update) (https://guide.elm-lang.org/architecture/).
Since I want to try writing a small CLI/TUI with bubbletea first anyway, porting it to ELM afterwards could be an interesting exercise.